home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000143_news@columbia.edu _Fri May 24 18:13:07 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id SAA06135 for <kermit.misc@watsun>; Fri, 24 May 1996 18:13:06 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id SAA20627 for kermit.misc@watsun; Fri, 24 May 1996 18:13:04 -0400 (EDT)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Path: news.columbia.edu!lamont.ldeo.columbia.edu!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!EU.net!usenet1.news.uk.psi.net!uknet!dispatch.news.demon.net!demon!netcom.net.uk!netcom.com!kientzle
  6. From: kientzle@netcom.com
  7. Subject: Re: Best efficiency ?
  8. Message-ID: <kientzleDrx4yE.2IA@netcom.com>
  9. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  10. References: <4o08gj$d5u@ns2.ryerson.ca> <31a47d81.389121497@128.230.1.4> <TOM.96May23115142@amber.ssd.csd.harris.com>
  11. Date: Fri, 24 May 1996 16:39:50 GMT
  12. Lines: 29
  13. Sender: kientzle@netcom10.netcom.com
  14.  
  15. In article <TOM.96May23115142@amber.ssd.csd.harris.com>,
  16. Tom Horsley <Tom.Horsley@mail.hcsc.com> wrote:
  17. >When I issue all the commands from the FAQ to give me a fast, clean, max
  18. >throughput kind of connection and start the download it just screams for the
  19. >first few kilobytes, then ...
  20.  
  21. It may or may not have anything to do with flow control per se.
  22. If your serial driver is dropping data (possibly due to flow control
  23. problems, possibly due to buggy drivers or scrambled hardware
  24. interrupts) then long windows and/or long packets are deadly.
  25.  
  26. If you're using a long window, long packets, and there's data loss,
  27. you'll see exactly the sort of behavior you describe: the sender will
  28. send a bunch of long packets (furiously blinking modem), but only one
  29. or two will be successfully received.  The receiver waits (no modem
  30. lights), eventually times out and re-requests a packet (modem blinks
  31. once), etc, etc.  Try selecting a small packet size and small window
  32. and gradually increasing them.  I suspect you'll find a point beyond
  33. which throughput degrades rapidly.  On one local connection, I found
  34. that I had to limit the (window size times packet size) to less than
  35. 1500.  Beyond that, throughput dropped to nothing.  After upgrading
  36. the serial drivers, suddenly large windows worked better.
  37.  
  38. If you're interested in the technical details of what's going on, you
  39. might be interested in the article I wrote for Dr. Dobb's back in
  40. February, which describes some techniques Kermit implementations can
  41. use to deal with this type of problem.
  42.  
  43.                                 - Tim Kientzle